Análisis Estructurado, considera que los datos y el proceso que transforman los datos son entidades separadas.

• Los objetos de datos se modelan en una forma que define sus atributos y relaciones.
• Los procesos que manipulan los objetos de los datos se modelan de tal forma que muestran cómo transforman los datos, mientras los objetos de datos fluyen por el sistema.

Objeto de Datos, representación de casi cualquier información compuesta que el software debe entender. Información compuesta se refiere a algo que tiene muchas propiedades o atributos diferentes.

Atributos, definen las propiedades de un objeto de datos y toman una de las 3 características diferentes. Se pueden utilizar para

1. Nombrar una ocurrencia del objeto de datos.
2. Describir la ocurrencia
3. Hacer referencia a otra ocurrencia en otra tabla

Relaciones, indican la manera en que los objetos de datos están conectados entre sí.

Comienza con la creación de escenarios en la forma de:

• Casos de Uso, describe un escenario de uso específico en un lenguaje directo desde el punto de vista de un actor definido.

El DFD tiene una visión del sistema del tipo Entrada – Proceso – Salida, es decir los objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento, y los objetos de datos resultantes fluyen al exterior del software.

Se presenta en forma jerárquica, es decir el primer modelo de flujo de datos representa el sistema como un todo. Los diagramas de flujo de datos subsecuentes refinan el diagrama de contexto, ya que proporcionan una cantidad creciente de detalles en cada nivel subsiguiente.

Especificación de Control (EC): Representa el comportamiento del sistema de 2 maneras. Contiene un diagrama de estado que es una especificación secuencial del comportamiento, y también puede contener una tabla de activación del programa: una especificación combinatoria del comportamiento.

Describe el comportamiento del sistema, pero no brinda información acerca del trabajo interior de los procesos que activa.

Especificación de Proceso (EP): Se utiliza para describir todos los procesos del modelo de flujo que aparecen en el nivel final de refinación.

El ingeniero de software crea una “miniespecificación” que puede servir como guía para el diseño del componente del software que implementará el proceso.

La clase se requiere para implementar una solución, es parte del espacio de solución; se manifiestan de la siguiente manera:

• Entidades externas
• Cosas
• Sucesos o Eventos
• Papeles
• Unidades Organizacionales
• Sitios
• Estructuras

Seis características de selección que se deben usar cuando un analista considera cada clase potencial para incluirlas en el modelo de análisis:

1. Información referida

2. Servicios requeridos

3. Atributos múltiples

4. Atributos comunes

5. Operaciones comunes

6. Requisitos esenciales

El primer paso del modelado basado en clases es la definición de clases, y se deben tomar decisiones (incluso subjetivas).

Proporciona un medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto.

Objetivo: Desarrollar una representación organizada de clases.

Responsabilidades: Atributos y operaciones relevantes para la clase.

Colaboraciones: Aquellas clases que se requieren para que una clase reciba la información necesaria para completar una responsabilidad.

Asociación: Define una relación entre clases. La multiplicidad define cuántas de una clase están relacionadas con cuántas de otra clase.

Estereotipo: Es un mecanismo de extensibilidad dentro del UML que permite a un ingeniero de software definir un elemento de modelado especial cuya semántica define el cliente. Se representan dentro de comillas angulares.

Paquete de Análisis: Una parte importante del análisis es la categorización. Los diferentes elementos del modelo de análisis se clasifican de una manera que los empaqueté como una agrupación, a la cual se le asigna un nombre representativo.

El modelo de comportamiento indica la forma en que el software responderá a los eventos o estímulos externos, realizando los siguientes pasos:

1. Evaluar todos los casos de uso para entender por completo la secuencia de interacción dentro del sistema.
2. Identificar los eventos que conducen la secuencia de interacción y entender la forma en que estos eventos se relacionan con las clases específicas.
3. Crear una secuencia para cada caso de uso.
4. Construir un diagrama de estado para el sistema.
5. Revisar el modelo de comportamiento para verificar su exactitud y consistencia.